Pure refactor of startArticleContentTranslation in models/article.ts.
The on-conflict / staleness gate at the front (insert-or-find the
placeholder row, decide whether work is needed) stays in the public
function.  The post-row-creation work — fetching author/tag context,
running translate(), writing the result back, sending the federation
Update activity, and kicking off post-translation summarization — moves
into a new private async helper runArticleContentTranslation(fedCtx,
queued).

No behavior change.  The synchronous setup phase (article-source
fetch) is still awaited before the translate() chain is scheduled, so
callers see exactly the same return timing as before, and the
translate-then/catch chain still runs in the background.

A defensive log-and-return guard is added when the helper is called
with a row that has originalLanguage IS NULL (the original-language
row itself); the existing public entry point never produces such a
row, but a forthcoming caller will pass already-existing translation
rows through this path.

Assisted-by: Claude Code:claude-opus-4-7

Inside the new runArticleContentTranslation helper, take a JS-side
claim Date as ownership stamp on the placeholder row before kicking
off the translate() chain.  The success UPDATE and the failure
DELETE both gate on the row's `updated` still equalling that claim
— a concurrent re-translation that resets the row out from under us
bumps `updated` past the claim, and our writes turn into no-ops
instead of clobbering the fresher placeholder with stale text or
deleting it on a stale failure.

A JS Date is used (rather than PG `CURRENT_TIMESTAMP`) because the
postgres driver hands back JS `Date` values truncated to ms while
PG `timestamptz` keeps µs precision; a CAS against a round-tripped
`CURRENT_TIMESTAMP` write would never match its own claim.  This
mirrors the claim pattern already used by startArticleContentSummary
in this file.

The race this prevents only becomes reachable in practice with the
forthcoming retranslation-on-edit code path, but the guard is
self-contained and the existing failure-cleanup test still passes,
so it lands ahead of that change as a pure correctness fix.

Assisted-by: Claude Code:claude-opus-4-7

Edits to an article's body now invalidate every existing translation
row for that article and re-runs the translator against the fresh
original.  Previously, translations stayed pinned to whatever text
they were generated from, so /ja, /en, etc. silently drifted out of
sync with the edited original.

The trigger lives in two pieces:

- updateArticleSource now returns an extra `originalContentChanged`
  flag set when the original-language `article_content` row's body
  actually changed.  The flag mirrors the existing summary
  invalidation gate: title-only edits do not set it, so a typo fix
  on the title doesn't fan out N+1 LLM calls; the body-changed gate
  also catches the case the summary path already cared about.  A
  successful `languageChanged` cannot reach this branch when
  translations exist (the self-FK on `article_content` re-throws
  23503 as `LanguageChangeWithTranslationsError`), so the flag is
  effectively `contentChanged`.

- A new restartArticleContentTranslations(fedCtx, articleSource)
  resets each translation row to placeholder state — copying the
  new original title/content into it, flipping `beingTranslated`
  back to true, and clearing summary state — then fires the
  extracted runArticleContentTranslation helper against each reset
  row in the background.

updateArticle reads the new flag and awaits the synchronous
claim-and-reset step so placeholders are visible by the time the
mutation responds; the actual translate() calls run in the
background, same as the initial translation flow.  Each
re-translation that completes sends its own federation Update so
peers see the original-language change first and then each
translation's refresh as it becomes available — the right
ActivityPub semantics.  The CAS guard added in the previous commit
keeps an in-flight stale translation from clobbering the new
placeholder with stale text on completion.

The summary-test callers of updateArticleSource only assert
truthiness on the return value, so the new return shape passes
through them unchanged.  The dedicated source-level test that
previously asserted "preserves translations" splits into two: one
for the body-change case (now asserting the flag flips and the
existing row is preserved here for the outer caller to invalidate)
and one for the title-only carve-out.  New end-to-end tests in
article.lifecycle.test.ts cover updateArticle's full body-change
and title-only paths.

Fixes hackers-pub#95

Assisted-by: Claude Code:claude-opus-4-7

Three fixes uncovered by an external code review of commits
302c242..422ee87.

1. Translate the freshest body, not the queued snapshot
   (models/article.ts).  runArticleContentTranslation's claim
   step now reads the row back via RETURNING and uses
   `claimed.title` / `claimed.content` for the translate input.
   This closes a race where two restartArticleContentTranslations
   calls interleave: the older restart's runArticleContentTranslation
   would otherwise translate the older body even after the newer
   restart wrote the newer body into the placeholder.  The claim
   WHERE also now requires `beingTranslated=true`, so the helper
   bails silently if the row has been completed (or deleted)
   between the caller queueing this run and the claim landing,
   instead of stamping a claim onto a no-longer-relevant row.

2. Make translation Update activity ids unique
   (models/article.ts).  Previously every translation completion
   reused `#update/${article.updated.toISOString()}` as the
   activity id.  `article_source.updated` is not bumped by
   translation completions, so the original-language Update and
   every per-locale translation Update for the same edit all
   collided.  The id now incorporates the target language and
   the translated row's own (just-bumped) `updated` so each
   completion mints a distinct id, regardless of how many
   locales finish in close succession.

3. Catch background retranslation kickoff failures
   (models/article.ts).  restartArticleContentTranslations did
   `void runArticleContentTranslation(...)`, which loses any
   rejection thrown by the synchronous setup before the internal
   `.then().catch()` chain is installed (e.g., a transient DB
   error during the claim UPDATE or the article-source fetch).
   Such rejections would surface as unhandled promise rejections
   in the runtime; they now go through a `.catch()` that logs
   the failed (sourceId, language) and the error.

All 29 article-domain tests still pass.

Assisted-by: Codex:gpt-5.5
Assisted-by: Claude Code:claude-opus-4-7

Wrap the read-original-then-reset-translations sequence in
restartArticleContentTranslations in a transaction that takes
`SELECT … FOR UPDATE` on the article_source row.  Concurrent
restartArticleContentTranslations calls (driven by back-to-back
edits to the same article) would otherwise each read their own
snapshot of the original-language body and then overwrite each
other's placeholder writes — the older restart's iteration could
land after the newer restart's, leaving the placeholder pointing at
the older body and the eventual translation reflecting that older
body even though a newer edit had committed.

The article_source row lock is the same row-level write lock that
updateArticleSource takes on its UPDATE, so concurrent edits and
restarts queue up cleanly without any new lock graph.  The actual
translate() round-trip runs after the transaction commits — the
runArticleContentTranslation calls are scheduled outside the tx
block — so the LLM call doesn't extend the lock window.

Follow-up to the previous commit (Address Codex review of the
retranslation flow), which addressed three of four issues; this
one closes the remaining stale-snapshot race that survived the
freshest-body claim refactor in runArticleContentTranslation.

Assisted-by: Codex:gpt-5.5
Assisted-by: Claude Code:claude-opus-4-7

Both models/article.background.test.ts and
models/article.lifecycle.test.ts had a private copy of the same
async-polling helper that watches for background-promise side
effects (translation completion, placeholder reset, summary
cleanup) without exposing the underlying promise to the test.
Move it to test/wait.ts so future tests don't grow a third copy
when they hit the same observation pattern.

Behavior is unchanged: same 50 ms poll cadence, same default
10 s deadline, same error message on timeout.

hackers-pub#283 (comment)

Assisted-by: Claude Code:claude-opus-4-7

runArticleContentTranslation()'s claim UPDATE only required
beingTranslated=true on the row, so two background runs scheduled
for the same (sourceId, language) by back-to-back edits would both
pass the claim check and both call translate().  The success /
failure CAS at the end still ensured only one write landed, but
the second translate() round trip was wasted LLM cost.  A related
concern is that JS Date is millisecond-precision, so two claim
values created in the same millisecond compare equal; the
existing CAS happens to remain correct because the first success
bumps `updated` to a new value that the second can no longer
match, but the protocol felt easier to reason about with a
stronger uniqueness story up front.

Add `updated = queued.updated` to the claim WHERE so each run only
claims the placeholder it was queued for.  When a later restart
re-stamps the row, the older run's claim turns into a no-op
instead of going through to translate().

For this CAS to be lossless, every writer that produces a row
the helper later treats as `queued` now stamps `updated` with a
JS Date (which round-trips through the postgres driver at the
same ms precision the JS side stores) instead of letting it
default to PG's CURRENT_TIMESTAMP (which keeps µs and would lose
precision on the round trip):

- startArticleContentTranslation()'s INSERT: explicit
  updated: queueStamp.
- startArticleContentTranslation()'s stuck-row recovery: an
  explicit re-stamp UPDATE before handing the row off to the
  helper, so the helper's CAS has a value to match.  Returns
  early without scheduling translate() if a concurrent writer
  took the row out from under us between the SELECT and the
  re-stamp.
- restartArticleContentTranslations()'s reset UPDATE: explicit
  updated: restartStamp instead of sql`CURRENT_TIMESTAMP`.

The claim WHERE in runArticleContentTranslation() then matches
this stamp exactly.

All 30 article-domain tests still pass; the existing fixtures
already insert with JS Date stamps, so no test changes are
needed.

hackers-pub#283 (comment)
hackers-pub#283 (comment)

Assisted-by: Codex:gpt-5.5
Assisted-by: Gemini Code Assist:gemini-2.5
Assisted-by: Claude Code:claude-opus-4-7

The translate() input in runArticleContentTranslation() passed
sourceLanguage as `claimed.originalLanguage ?? originalLanguage`,
where the right-hand side was the destructured local from the
caller-provided `queued`.  The fallback was dead code: the claim
WHERE required `beingTranslated=true`, and the schema check
`article_content_being_translated_check` makes that imply
`originalLanguage IS NOT NULL`, so `claimed.originalLanguage` is
always set on a row that came back from the claim's RETURNING.

Drop the fallback and use a non-null assertion on
`claimed.originalLanguage` (drizzle types the column as nullable
because it is nullable in general, but in this position the
schema guarantees otherwise).  A short comment captures the chain
of guarantees so a future reader doesn't reach for the same
defensive `??` again.

hackers-pub#283 (comment)

Assisted-by: Gemini Code Assist:gemini-2.5
Assisted-by: Claude Code:claude-opus-4-7

restartArticleContentTranslations() acquired the article_source
row lock with raw SQL via tx.execute(sql\`SELECT 1 FROM ... FOR
UPDATE\`).  Drizzle exposes the same primitive idiomatically as
.for("update") on a select query, which keeps column references
and parameter binding consistent with the rest of this file's
query style.  Same lock, same semantics, no behavior change.

hackers-pub#283 (comment)

Assisted-by: Gemini Code Assist:gemini-2.5
Assisted-by: Claude Code:claude-opus-4-7

splitTranslationTitleAndContent() previously took the first H1
line anywhere in the output as the title, dropping any text
before it on the assumption that it was model commentary.  That
handled a "preamble before # Title" case nicely but introduced a
data-loss path: when the model omitted the article-title H1 and
the body happened to contain its own H1 section heading, the
parser silently truncated the article (mis-promoted body H1 to
title, dropped the intro paragraphs above it).  Silent truncation
is a worse failure mode than a visible-but-ugly title.

Anchor parsing to the first line of the trimmed output:

- The first line becomes the title.
- If it begins with `# `, the marker is stripped; otherwise the
  whole line is the title verbatim.
- Everything after the first line becomes the body, untouched.

The strict implementation also folds in the related cleanup of
the prior fallback branch.  Because `trimmed` is the result of
`String#trim()`, it is guaranteed to either be empty or begin
with a non-whitespace character, so the previous `findIndex` for
the first non-empty line was redundant and is now removed.  The
H1-marker regex is restricted to a single `#` followed by
whitespace so a first-line `## Section` is taken verbatim
instead of being mis-stripped.

Tests in models/article.translation-split.test.ts are updated to
match the new behavior: the preamble case now keeps the preamble
visible as the title with the body's `# Title` framing
preserved, and the rest of the cases (clean H1+body, no-H1
fallback, first-line H2, body H2 sections, empty input,
H1-only input, title trimming) continue to pass unchanged.

hackers-pub#283 (comment)
hackers-pub#283 (comment)

Assisted-by: Codex:gpt-5.5
Assisted-by: Gemini Code Assist:gemini-2.5
Assisted-by: Claude Code:claude-opus-4-7